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(57) Abstract: Methods and associated structme for verifying the identity 
of a consumer in a financial card transaction. The method provides for issu- 
ing at least one aothozization request through standard caid transaction net- 
works and protocols. The amount of each transaction and/or the number of 
transactions is preferably randomly generated. If the purported cardholder 
confirms the random amounts and or number of transactions the purported 
cardholder is identified as an authorized cardholder. The authorized transac- 
tions are never captured (completed) and hence are removed by the issuing 
institution in accordance with the institutions rules for the account. Since the 
transactions are never captured, no funds are transfened to or from the card 
holder's account by virtue of the veri&ation process. Further, the transac- 
tions aie commimicated to the institution using standard netwoiics and pro- 
tocols available from all card-issuing (or ^rvicing) institutions and available 
to all merchants that accept cards for customs purchases. Still furdier; the 
same method may be used for verifying cardholder identity in both debit and 
credit card proposed transactions within a near-real-time environmj^L A 
further a^^ect of the invention provides for verifying an e-mail address as- 
sociated with the verified authorized cardholder: The verified card account 
information and the associated, vmjfied e-mail address of the cardholder is 
recorded in a database of a secured server. A merchant confronted with a 
proposed transaction using a card account may request veiijBcation from tiie 
secured seiv^ An e-mail message is sent to the verified cardholder at the 
verified e-mail address. The cardholder's reply then accepts of rejects the 
proposed card transaction. 
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METHODS FOR VERIFYING CARDHOLDER AUTHENnCITY AND FOR 
CREATING BILUNG ADDRESS DATABASE 

Problem 

5 The present convention relates generally to electronic commerce 

systems and more specifically relates to credit/debit card authorization and 
verificaUon coupled with the utilization and generation of a local billing and 
consumer identification verification databa^. 

In commercial transactions utilizing credit cards and debit cards 

10 (collectively refenred to herein as Unandai cards'^, merchants are generally 
required to obtain authorization for changing a particular transaction. In 
general, such authorization Is obtained by communicating with the bar^ (or 
other issuing institution) and obtaining oral or electronic authorization to 
transact a particular amount on behalf of the customer. Should a transaction 

IS receive authorization, the decision to complete (or "capture") the transaction 
falls to the merchant and depends lai^ely on whether or not the merchant is 
able to sufficiently verify the identity of the consumer. In feice-to-face 
transactions, merchants will often require the (X}nsumer's hand-written 
signature - confirmed by a picture ID. When conducting transactions over an 

20 electronic networic such as the Internet, such traditior^ means of identity 
verificaflon are not available. 

At present, the most widely u^ verification system used to detemnlne 
cardholder identity for such "card not present" (i-O-t Internet) transactions is 
the Address Verification Sennce (also refen'ed to herein as "AVS'O- AVS is a 

25 proprietary system offered and supported by the major credit card companies 
as a method of verifying the cardholder's billing address - theret>y assisting 
merchants in the identifying of possible credit card fraud. In general, a 
merchant may require entry of the consumer's billing address along with the 
consumer^ oredit card number. These two elements of information are then 

30 electronically or orally conveyed via the AVS system to the issuing institution 
for the purpose of verifying the cardholder's billing address. If the known the 
billing address mab^es ttie address provided by the consumer, the merchant 
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may then make ain infomfied deci^on as to whether or not to accept the 
consumer's tran^ction. 

The AVS system is neither mandatory nor impoaed on merchants. 
Rather, it is merely a source of information for merchants to use to gain 

5 confidence that the proposed credit card transaction is not fimidulent Despite 
the fact that the AVS system verifies tiie consumer's address, the merchant 
may still reject the consumer's proposed transaction for other reasons. 
Simliarty, despite the fact that the AVS system may not match the consumer's 
supplied address, the merchant may accept tiie propose credit card 

10 transaction and risk the possibility of fraud. 

Further it shouM t3e noted that the AVS system is voluntary on the part 
of issuing institutions. Not all institutionetiiat issue credit/debit cards choose 
to participate in the AVS system. Tliough all banks have a significant incentive 
to assist their merdiants reduce their exposure to credit card fraud, several 

15 U.S. banks and a majority of intemational banks dioose not to participate in 
the t^nk»lly complex AVS system. l\Aerchants accepting credit card 
transactions from credit cards issued by banks that do not participate in A>^ 
are often forced to make final transacticm deci^ons without significant 
verific^on information available. 

20 A number of prior solutions have sought to address the problem of 

inconsistently available verification infonnation from card-issuing institutions, 
in genera!, such solutions provide an externsU Q.e., third party) source of 
verification infonnation - i.e.. independent of the issuing institution decision to 
provide AVS servtoes. 

25 At least one technique (known commerclaily as 'Vertfled By VISA™"^ 

simply requires each cardholder to call their issuing bank and as^n a PIN 
(personal identification number or password) to their card. The PIN is not 
imprinted on the card. The issuing institution is tiien able to verify tiie 
registered PIN when requested to do so by a merchant attempting to verify a 

30 consumer's transaction. This method still requires the issuing Instifajtion to 
cooperate in that each institution must associate PiNs with their issued cards 
and independently provide tfie accompanying verification service for 
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merchants. 

Another solution exemplified by Unrted States Patent Numt>er 
6,282,658 attempts 1o verify a user's identity by comparing user input to a 
datat>ase of known user Infbrmatlon. This method presents a paradigm 

5 wherein a user is aslced questions to verify the user's identity. The teachbigs 
are not as speclfioally directed to verification of a cardholder's identity by a 
merchant confronted with a proposed transaction by a consumer In 
possession of the card number. 

Another solution typified by United Stales Patent Number 6,029,154 

10 provides for verifying a proposed card transaction by a number of weighted 
factors relating to history of past tian^ctions with the card. This proposed 
sdution teaches anaiysis of past loHJwn transactions to detemnine the 
similarity of the present proposed taiansaction with histOTical trends. A dosefy 
related solution In United States Patent Number 6,108,642 requires 

IS information from the user r^arding a second, relatod card number to 

ccMTipare the proposed transaction to prior recorded tran^ction information 
relating to troth card numbers. 

In yet anotiier solution, recent proposals have suggested determining 
an individual's geographic location from the IP address of the client process 

20 attempting an online transaction using a credit/debit card. The location so 
determined can be used to identify clear cases of fraud in that the same card 
may not be used in multiple locations around the world at nearly the same 
time. 

A significant number of prior techniques use "biometric" information to 
25 verily the user identity In a proposed card transaction. A specialized writing 
implement measuring various attributes of the signature writing process as 
well as fingerprint sensors is provided that determines a matc^ or no match of 
the signature (United States Patent Number 6,307,956). Another proposes a 
^eech recognition system to recognize itie user's Identity from a spoken key 
30 phrase such as the card number, a PiN or password (United States Patent 
Number 6.292,782). Stili ano^er combines voice recognition and video 
parameter rscognitton to verify the identity of a user for purposes of a secured 
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transaction (United States Patent Number 6,219,639). 

A number of present solutions apply digital encryption in ttie form of 
"oertjflcates'' or "smartcards" to enhance verification of a user's identity or of a 
transaction. See for example United States Patent Numbers 6,125,349 and 

5 5,590,1 97. Several sucii prior solutions are fooised on verlficaHon of details 
of a particular transaction as opposed to verification of ttie user's identity in 
any transaction. See for example United States Patent Numbers 6,226,624, 
5,991 ,41 1 and 5,988,497. 

One preserrt solution applies one of two different methods to enable 

10 verification of a consumer's identity. PayPal utiiizies tediniques to verify a 
user's identity for transaction on dieddng accounts or with a credit card, in 
concept the techniques vary only slightly but each metfiod essentially 
completes 0-e., carvtures) small transactions on the user's acccxjnt and ask 
the user to verify tiie results of the completed transactions. Technically each 

15 method relies on different systems for verification of the amounts, information 
regarding PayPal accounts and methods is available from tlieir Web site at 
httpV/Www.paypai.com. 

To verify the identity of a checking account holder^ ttansacHon, PayPal 
issues two transactions that result in two small deposits to the user's cheddng' 

20 account. The two deposits are each for random values less than $1 .00. 
PayPal then instructs the checking account holder to confirm the amount of 
the two small deposits, if the user verifies the amount of the two deposits, the 
user is presumed to be the proper owner of the bank account (presuming that 
the bank would only divulge such informatton to the rightful owner of the 

25 account) . PayPal is able to accomplish this method by utiliang a ^andard for 
bank communications Involving a private banking network and assodafed 
protocols maintain by Automated Clearing House (ACH). These deposit 
transactions complete actual money transfers from the accounts of PayPal to 
tlie account of a new user ^ough a small amount). PayPal intends tfiat the 

30 user virill keep the deposited dollar as a byproduct of starting a PayPal 

account Principally however, the deposite are needed for PayPal to perform 
ttie requisite auttiorization. This cost associated with ttie PayPal system can 
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be significant in casii flow terms - even though the investment may t>e 
recouped many fold through ongoing sub^uent tFansactions. 

This method used by PayPal relies on the ACH proprietary networks 
and protocols and is therefore not specifically applicable to verification of a 

S user's identity in a credit card tran^ictlon 

To verify the identity of a credit cardholder, PayPal completes a similar 
transfer of money" transaction (but in reverse) by charging the purported 
user's credit card account for $1 .95. In technical detail, such a transaction is 
actually perfonmed as a three-step process. Rrst the account Is "authorized' 

10 for a $1 .95 charge (to malce sure that the funds are available) and then the 
authorization is "c^tured" to complete the "transfer of money* transaction. 
Such captured (completed) transactlone will then appear on the user's next 
monthly statement for the account (while Incomplete transaction would not 
s^ypear on the end-of-month billing statement). In the desralption field 

15 Cdescrfptor^ of the captured transaction, PayPal Includes a dynamically 
generated ID number and aslo the user to verily that ID number as a third 
step in the process, if the user properly verifies the generated ID number 
found on the billing statement in the capture's descriptor, the u^ Is 
presumed to be the owner of the account by knowledge derived from the 

20 captured transaction appearing on monthly statement. 

This generated ID number is not usually available on the user's credit 
card account for 1-3 business days (and up to several weeks In the case of 
International" cards). l=or this reason, PayPal is often unable to Immediately 
O.e., at the point of sale) authenticate a cardhoklei's identity as the cardhokJer 

25 must weA for the captured tran^u;tion to be posted to their account to retrieve 
the generated descriptor ID and hence authenticate their identity for PayPal. 

Further, PayPal actually completes (captures) the charge transaction to 
the user's credit card account. The cardholder is therefore actually 
responsible fbr initially paying the $1 .95 charge. PayPal later refunds the 

30 cardholder for this charge. However, the process of an initial capture and 
eventual credit/refund amount to two, unique transaction services resuite in 
sen/ice fees generally billed to PayPal by the card institutfon (i-e., the 
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merchant in the eyes of the card inst'rtutton). 

In terms of cost, time and general efficacy, it is evident from the above 
discussion that a need exists for lnq>roved verificalion techniques to quiddy 
verify the identity of a cardholder in a debit or credit card "card not present* 
5 transaction. 

Solution 

The present invention solves the above and other problems, thereby 
advancing tlie state of the useful arts, by providing methods and associated 

10 stmcture for rapidly verifying the identity of. a cardholder for both debit and 
credit "card not presents transactions without actual transfer of funds in or out 
of the cardholder's account in the verification process and without requirir^ a 
restnjcturing of industry protocois or ^lintered institutions to independentty 
adopt and Integrate new servloe technoiogies. More specificaily, ttie present 

15 invention provides for an effective method for verifying the cardholder's 
identity that may be used for both debit card and credit card proposed 
transactions. In one aspect of the invention, a method provides for 
authorizing, but not capturing or completing, one or more transactions of 
randomly generated amounts used as a temporary identification. Such 

20 "authorizations" occur in near-real-time In that they on temporary banldng 
records that are almost immediately available for the cardholder's reference 
and confirmation. The con^mer (purported cardholder) is then instructed to 
contact their banic or other issuing institution to obtain the amourtte of the 
authorized, incomplete transactions, if the customer correctly verifies the 

25 amounte (i>e. . verifies tlie temporary identification code), the user may be 
presumed to be the cardliolder by virtue of access to the secured information 
obtained from the t>anl< {or other card-issuing institution). 

Such a method of the present Invention is usable over Industry 
standard, open networks acoessUrie to ail mercliante and supported by ail 

30 card-i^uing/servicing Institutions. Since the transactions are authorized but 
never captured (completed), no money is actually transferred to or from the 
cardhoidei's account. Rather, the authorized amounte on tfie account merely 
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explTB as incomplete transitions. The transactions are preferably of relatively 
small amounts so as to avoid unnTOessary encumbrance of tlie account. 

Another aspect of tlie present Invention combines the atK>ve 
veriflcalion technique with e-mail verificatton to pro\ride a low cost, easily 

5 accessed online verification technique for post-auflienticated account 

transactions. A cardholder creates an account under the present invention by 
logging into a secure server site and supplying three elements of information - 
an e-mail address, a debit or credit card number for an account (witii 
expiration date) and a postal address for billing/statements on the account if 

10 the (^d account is unknown to the server site (not previously recorded in its 
local database), the above method is first used to verify a cardholder^ 
identity. This step verifies the user as an authorized cardholder. Next, an e- 
maii vmlflcaUon Is sent to the supplied e-mail account asking the user to reply 
to the e-mail message wftti an independentiy suH>Iied verification ID code. 

15 This step verifies the user as the owner of tiie e-m£ul account (i>a., ono witii 
access to the e-mail account). With these verifications complete the 
information is entered into the servei's database. 

Wlien a purchase transaction is proposed using the previously 
authenticated card account, the merchant may request verification of the 

20 proposed transaction from the server site. Verification is performed by 

transmitting an e-mail message to the verified e-mail account associated with 
tiie card in the'server's database. The e-mail menage preferably provides the 
cardholder with tiie details of the proposed transactfon along with a 
transaction ID (i.e., PiN or other temporary identificatfon code infonnation) 

25 and requeste the user to reply to the e-mall wHh acceptance or rejection of the 
proposed transactkm. Since the e-mail address has been verified as 
belonging to the verified cardliokier, the acceptance or rejection of the 
specified transaction ID may be presumed as a vaiki response from the 
vertfl^ cardholder. The response is then relumed to the merchant for further 

30 processing of the transactfon. 

Brief Description of the Drawings 
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RgurB 1 is a flowchart describing a method of the present invention 
operable to verify the identity of a puiported cardholder. 

Rgure 2 Is a flowchart describing a method of the present Invention 
operable to verify an e-maii address to be assodated with an authorized 
5 cardhdder of a (^rd accounL 

Rgure 3 is a flowchart of a method of the present invention operable to 
verify a particular purchase bansaction using the verified account and e-mail 
information determined in accordance with methods of the present invention. 

Figure 4 is a bloci^ diagram of systems and data flow there between for 
10 s^tems involved In purchase transaction in accordance with the methods of 
tiie present Inventkm. 

F^ure 5 is a biocic diagram of systems and date flow there between for 
systems involved in verification of a purported cardholder's Identity as an 
authorized cardholder In accordance with the present invention. 

15 

Detailed Description of the Preferred Embodiments 

While the invention is susceptible to various modifications and 
alternative forms, a specific embodiment thereof has been shown by way of 
example In the drawings and \m\\ herein be described in detail. It should be 

20 understood, however, that it is not Intended to limit the invention to the 
particular form disclosed, but on the contrsuy, the invention is to cover all 
modifications, equivalents, and alternatives ^ling within the spirit and scope 
of the invention as defined by the appended claims. 

Rgures 4 and 5 are bioci< diagrams depicting s^ems in which 

25 methods of tlie present Inventions are operable and also depicting data flow 
between the >^ous s^tems. Those ^ied in the art will readily recognize 
any number of system configurations and interconnection topologies that may 
be used for each depicted system and communication patii of flgures 4 and 5. 
In particular, each "s^tem" may be a computing device, a point-of-sale 

30 transaction device, etc. Further, the patiis Interconnecting the various systems 
may utilize any number of equivalent communication techniques including 
computer to computer networic prooe^ng, wide area networic connections 



8 



wo 03/017049 



PCT/US02/25785 



such as the Internet, proprietary private networks, vofoe communications, etc. 
The biodc diagrams of figures 4 and 5 are tiierefore Intended as 
representative of a broad dass of s^tem conf^urations, devices, and 
Interconnecting communications media all of whidi are weil-ioiown matters of 
S design choice to tliose of ordinar/ sidii in the art. 

In parHcuiar, figure 5 depicts the systems and data flow involved in 
constructing and maintaining iocal verification services 502 and its associated 
database 508. In pauticuiar, upon request of a cardholder or merchant (not 
shown), iocai verification services 502 attempts to verify the identity of a 

10 purported cardholder. In partfcuiar, In an exemplary preferred embodinient, 
local verification services 502 issues authorization requests for one or more 
authorizations the total amount of which equals son\6 predetermined v^ue. in 
one exemplary preferred emt>odiment, two authorizations are generated eadi 
having an amount greater than one dollar but less ttian two dollars (ue., 

IS enough to insure Infrastmcture recognition and acceptance of the Individual 
autfiorizations but not so much as to unnecessarily, though temporarily, 
burden the account). 

Those sidiled In the art will recognize that any number of transactions 
may be Issued so long as the account is not unnecessarily burdened. Further 

20 the toted amount of such transactions may be any amount again so long as 
the account is not unnecessarily burdened. The purpose is to randomize the 
total amount and/or number of trsmsactions so as to preclude a fraudulent 
card account user from guessing at the verification information. The randomly 
selected amount of each transaction and/or the total amount therefore serves 

25 as temporary identification code to permit electronic, near-real-time 
verification of the card user as an authorized cardholder. 

The authorization reque^ so generated are issued via path 510 to the 
card-issuing or servicing Institution 500. Processing of such authorization 
requests are standard features available from every institution supporting 

30 debit or credit cards. Path 51 0 may be any communication medium and 

protocol suitable to communicate authorization requests to a c»fxMssuing or 
servicing Institution. For example, the Internet, proprietary computer network 
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communications and telephonic communications may be used for this 
purpose, n will be noted that authorization requests do not actually transfer 
any funds to or from the cardholder's account. Rather, the verification request, 
if never completed or captured, is m^ty deleted after a predetermined time 

5 t>y the systems of the card-Issuing or servicing institution. 

FolloNAring issuance of the plurality of authorization requests to the card- 
issuing or sen/idng institution, the purported cardholder Is directed to verify 
the amount of each of the Individual authorization requests. Path 514 from 
local verification services 502 to cardholder system 504 is used to so direct 

10 the cardholder. As at>ove, path 51 4 may utilize any appropriate 

OHnmunlcaUon medium and protocol for this Intended purpose Including 
computer network ccNnmunications and voice communications. The 
cardholder system 504 then requests and receives the indlvlduai amounts for 
each authorization request The request and receipt of such information via 

15 path 51 2 from <»rd-lssuing or senndng institution 500 is a standard feature 
av^iable firom any card-Issuing or senncing Institution for an autliorlzed user 
or holder of a partteular card. As above, numerous equivalent communication 
media and protocols may be used for e}«;hange of tills InfcNinaUon. In receipt 
of the proper amounts of each authorization request, the cardholder system 

20 retums In the proper amounts via path 51 4 to the local verrfication services 
502. In response to receipt of the proper amounts from the cardholder system 
504, local verification services 502 is assured that the purported cardiiolder is 
In fact that a properly authorized cardholder or u^r in accordance with the 
rules of the card-Issuing or servicing institution. This verified information 

25 then stored in dalBt>ase 508 malrrtained by local verification services 502. 
Figure 4 depicts systems involved In verification of a particular 
purchase transaction based upon previously verified financial account In 
conjunction witii a previously authenticated e-mail account More specifically, 
a cardholder system 402 initiates a purchase request via path 41 2 directed to 

30 a merchant system 400. As noted above, ttie cardholder's system 402 and 
merchant system 400 and the communication between the two may be 
Implemented by any of a variety of equi>^ent devices, topologies, and 
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oommunlcations media. For example, the systems may be mmputb^ 
systems oommunlcating via a wide area networi( such as the Internet or 
steuidard point-of-sale devices and communication where a purc^iaser 
(purported cardholder) and merchant communicaie orally ^er in person or 

S over a telephone. The merchant system 400 then r^uests verfflcation of the 
purc^iase tran^cUon from local verificatton ^rvtees system 404 via path 41 0. 
Local verification sen/ices 404 inspects database 408 to determine the 
authenticated e-mail account for the cardholder of the authenticated card 
account. An e-meu'l message is generated by local verification services 404 

10 and sent via the path 414 to the cardholder's system 402. The authorized 
CEudholder (or authorized us^ of tlie verified e-mall account) then replies to 
the transmitted e-mail message via path 414 indicating acceptance or 
rejection of the proposed purchase transaction. The received reply indic^ng 
eKX»ptance or rejection Is then conveyed via path 410 from the local 

15 verification services 404 back to the merchant system 400. Merchant system 
400 then makes a determination &s to whetiier or not to complete the 
proposed purchase transaction. 

Rgures 1 through 3 de^ribe methods of the present inventions 
operable in the \^rious systems of figures 4 and 5. In particular, figure 1 is a 

20 flowchart describing operation of the metiiod of the present inventions 
whereby a locaU verification server is requested to verify the identity of a 
purported cardhoMer. Typically, such a request is initiated by a merchant 
system to verify the identity of a purchaser as an authorized cardholder or 
usor. The method of figure 1 is therefore preferably operable within local 

25 verification services system such as depicted in figures 4 and 5. 

Element 1 00 is first operable to generate a plurality of authorization 
requeste and to transmit the requests to the card-issuing or servicing 
Institution. Processing of authorization requests is a standard feature a^^lable 
from most card-issuir^ and servicing organizations to permit mercharrts to 

30 verify sufficient credit is available in the purchsser's card account to complete 
the proposed transaction. As noted above, in one exemplary preferred 
emt>odiment, two transactions are randomly generated totaling some 
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predetermined amount Those skilled in the art will recognize that any number 
of requests may be generated totaling any selected predetermined amount. 
ICey to the invention Is some randomizing of tiie amounts and/or the number 
of transactions so that an unauthcvi^d user cannot simply guess at the 
5 correct values when verifying the transactions (as discussed further herein 
below). It is further key that the authorized transaction amounts are never 
captured or completed as finished transactions and therefore no funds are 
ever transferred to or from the cardholder's account 

Element 102 then receives the consumer's input to confirm the 

10 amounts of each Individual authorization generated by element 100. Element 
104 tlTen determines whether tlie consumer input has correctly confirmed the 
amount of each authorizatton request (as well as the number of requeste). If 
so, element 106 identifies the consumer as an authorized cardhokier for this 
card account Such a confimnlng message Is constaicted and returned to the 

15 requesting merchant by operatton of element 110. 

if element 104 determines that the consumer has not supplied proper 
confirmation of the amount of eadi individual authorization reque^, element 
108 Identifies the consumer as an unauthorized c^mdholder or us^. Element 
110 tfien retums suc^ a message to the requesting merchant 

20 Rgure 2 is a flowchart descn'bing a method of the present invention 

operable within a local verification services system to verify the e-mall account 
for an authorized cardholder or user, in an exemplary preferred embodiment, 
the method of figure 2 Interacts with the user via standard internet features 
including e-mail. HTTP Web browsing or mobile communication protocols 

25 (such as WAP). 

Element 200 Is first (^erable to present the consumer with a Web page 
requesting card acoount/k>gin information. Element 202 Is then operable to 
lookup account infonmation using the ktentified card account number in tlie 
local database associated with the local verification services system. Element 
30 203 then determines whether the identified card account is already known to 
the \o(xi verification services system Q.e., found in the local databa^). if the 
account is already known to the s^em (i>e., loc^ited in he local database), 
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proces^ng continues at element 206 as discussed below. If the identified 
account numt>er Is not presently icnown to the local verification sendees 
system, elements 204 and 205 are operable to perform apprq3riate 
verification processes as descrit>ed above and to store such verified 

5 information In the loc^ database maintained by the local verification services 
system, in particular, element 204 is operable to verify the cardholder^ 
identity as discussed at)ove with respect to figure 1 . After properly verifying 
the cardholder's sojtiientlcity, element 205 is then operable to store such 
verified account Information in the local database associated with the local 

10 verifii^on services system. Processing then continues at element 206 as 
di^MJSsed further below. 

Element 206 Is operable to present the verified and known cardholder 
with a Web page requesting the cardholder's e-mail account information. 
Element 207 receives such information from the cardholder. Element 208 then 

15 generates an e-mail message to the provided e-mail account In an exemplary 
preferred embodiment the e-mail message includes a randomly generated 
verificaftion value. Element 209 then presents the cardholder with a second 
Web page requesting that the cardholder returns in a field of the second Web 
page the randomly generated verification value transmitted to the cardholder's 

20 identified e-maii account. Element 21 0 is then operab\e to receive the e-mail 
verification values from the cardholder. Element 21 1 then verifies that the 
correct verification value has been returned by the cardholder indicating tliat 
the e-mail account is property associated wftii the verified cardholder account 
If so, element 212 stores tfie verified e-maQ account information with the 

25 known cardholder account information in a local database. As discussed 
forther her^n below, the verified e-maii account may then be used to verify a 
proposed transaction from the known cardholder at the request of a merchant. 

Figure 3 is a flowdiait describing a method of the present invention 
operable within a local verification sen/ices system to verify a particular 

30 proposed purchase transaction associated wrtii a verified financial card 
account information for the verified card account is preforably stored in the 
datat)ase of the focal verification services system. 
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Element 300 is first operable to receive a request from a mercharrt to 
verify a proposed purchase transaction using an identifiecl card account. 
Element 302 is then operable to loolcup account information using the 
identtfi^ card account number In the local database associated with the local 

5 verification services system. Element 304 then determines whether the 
Identified c^d account is already known to the local verific^on services 
system 0-e.. found in tiie local database). If the identified account numt>er is 
not presently known to the local verification services system, element 306 
through 310 are operable to perform appropriate veriflcation processes as 

10 described above and to store such verified informatton in the local database 
maintained by the tocai verfficatlon services system. In paitteular, element 306 
is operable to verily the consumer's kJentity as discussed above with respect 
to figure 1 . After properly verifying the cardhoMer's autiientteity, element 308 
is then operable to store such verified account information in the local 

15 database assodated with tlie tocal vertficatk>n services system. Element 31 0 
then obtains a verified e-mail account to t>e assodafted with the verified and 
known cardholder account infbrmatton as discussed above udth respect to 
figure 2. Such a verified e-mali account information is stored in the local 
database associated with the verified card information. Processing then 

20 continues at element 31 2 as discussed further below. 

If element 304 determines that the identified card account Is already 
known to the local verlfteation services system (l-e., found in the local 
database), processing continues with element 312 to e-mail the proposed 
transactton information to the kriown e-mail account of the known cardholder. 

25 Element 31 4 then receives an e-mail reply from the authorized, verified 

cardholder indicating the cardholder's acceptance or rejection of the proposed 
transactkm. The cardholder's acceptance or rejection of tiie transaction is 
then returned to the requesting merchant to permit the merchant to determine 
whetlier to complete the proposed transactton. 

30 

While the Invention has been illustrated and described in tiie drawings 
and foregoing description, such illustration and description Is to be consklered 



14 



wo 03/017049 



as exempteuy and not restrictive in character, it being understood that only the 
preferred ^bodiment and minor variants thereof have been shown and 
descrarad and that all changes and modifications tiiat come within the spirit of 
the Invention are desired to be protected. 
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Claims 

What is cfalmed is: 

1 . A method for sufthentteEding the identity of a consumer as an 
5 authorized cardholder of a financial card account comprising flie st^s of. 

issuing at least one card authorization request for said financial card 
account wherein the amount of each authorization request is randomly 
selected; 

receiving information from said consumer regarding each of ^d at 
10 lea^ one authorization request; and 

verifying said consumer as said authenticated cardholder in response 
to receipt of correct infomrialion regarding said each of said at least one 
authorization request 

15 2. The method of claim 1 wherein the step of receiving said information 
comprises ttie step o^ 

receiving infomiation regarding the amount of said each of said at least 
one authorization request 

20 3. The method of claim 1 wherein the step of receiving said infomiation 
comprises the step of: 

receiving Information regarding the number of authorization requests 
issued of said at least one authorization request. 

25 4. The method of claim 1 wherein the step of receiving said Jnformatton 
comprises tlie st^ of: 

receiving information regarding the total amount of the sum of the 
amount of said each of ^d at least one authorization request 

30 5. The method of claim 1 wherein the step of issuing comprises the step 
of: 

issuing two authorization requests to ^d iderrtified electr<Hiic account 
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wherein the amount of each authorization request is randomly selected and 
the total amount of said two authorization requests equals a predetenrnlned 
amount. 

5 6. A method for autfienticating the Identity of a consumer as an 

authorized cardholder of a financial card account comprising the steps of. 

dynamically generating a temporary identification code; 

locating, in a database, information regarding said financial card 
account wherein said information includes an e-mail account owned by said 
10 autiiorized cardholder; 

sending an e-maii message to said ennail account in response to 
locating said infonmalion, wiiereln said message Includes said temporary 
identificaHon code and wherein said message requests the e-mail message 
recipient to validate said card transaction request; and 
IS receiving a reply from a user of said e-mail account indicating 

acceptance or rejection of said card transaction, wherein said reply includes 
said randomly generated information, and 

wherein the step of authenticating comprises the steps of: 

determining whether said randomly generated infonmation in said reply 
20 matches said randomly generated information in said message; and 

validating said card transaction In response to receipt of said reply 
indicating acceptance of said card transaction and in response to a 
determination tiiat said randomly generated information in said message and 
in said reply mateh. 

25 

7. The method of dalm 6 wherein In response to f^lure to locate said 
Information in ^d database, the metlKKi further comprises the steps of: 
verifying the Identity of said authorized cardholden 
otrtaining an e-maii account to be associated vnth ^d financial c^d 
30 account; and 

verifying said e-maii account as associated with said authorized 
cardholder. 
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8. The method of daim 7 wher^n the step of verifying the identity of said 
cardholder comprises tfie steps of: 

issuing at least one card authorization request on said finandal <^ 
5 account wiiereln the amount of each authorization r^uest Is randomly 
selected; 

receiving from said consumer information regarding each of said at 
least one authorization request; and 

verifying the identity of ssdd consumer as an authenticated cardholder 
10 in response to receipt of correct information regarding said eac^ of said at 
least one auSyonzatian request. 

9. The method of claim 8 wherein the step of receiving said information 
comprises the step ol: 

IS receiving information regarding trie amount of said each of said at least 

one authorizalkxi request 

1 0. The metiiod of daim 8 wherein the step of receiving said information 
comprises the step of: 

20 receiving Infomnation regarding the number of authorization r^uests 

issued of said at least one authorization request. 

1 1 . The method of daim 8 vtriierein the step of receiving said infomnatlon 
comprises the step ot 

25 receiving information regarding the total amount of the sum of ttie 

amount of said eadi of said at least one autliorization request. 

1 2. The method of daim 8 wh^in the step of issuing comprises the step 
of: 

30 issuing two authorization requests to the finandal card account wherein 

the amount of each authorization request is randomly seleded and the total 
amount of said two authorization requests equals a predetermined amount 
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13. The method of dalm 8 wherein the step of verifying said e-mail account 
comprises the of: 

presenting a Web page to a user of said e-mail account; 
5 sending an e-mali message to said e-mail account wherein said 

message indudes an authorization code; and 

receiving said authorizab'on code from said user in a field of ^d Web 

page. 

10 14. A system for authenticating the identity of a consumer as an authorized 
cardholder of a finandal card account comprising: 

meauis for issuing at least one card authorization request for asdd 
finandal card account wherein the amount of each authorization request is 
randomly seleded; 

15 means for receiving information from ^d consumer regeu'ding each of 

said at least one autfiorization request; and 

means for verifying said consumer as said authenticated cardholder In 
response to receipt of correct infbrmatlon regarding said each of said at least 
one authorization request 

20 

1 5. The system of claim 1 4 wherein the means for receiving said 
information comprises: 

means for recei\nng infomnation regarding the amount of said each of 
said at least one authorization request 

25 

1 6. The system of claim 1 4 wherein the means for receiving said 
information comprises: 

means for receiving information regarding the number of authorization 
requests issued of said at least one authorization request 

30 

17. The system of daim 1 4 wherein the means for receiving said 
information comprises: 
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means for receiving Information regarding the total amount of the sum 
of tlie amount of said each of said at least one authorization request 

1 8. The system of dalm 1 4 wherein the means for issuing comprises: 
5 means for issuing two authorization requests to said identified 

electronic account wherein ttie amount of each authorizaticvi request is 
randomly selected and the total amount of said two authorization requests 
equals a predetermined amount 
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